1. Field of the Invention
The present invention relates to a technology for selecting one from requests issued by each unit by a crossbar to which a plurality of units are connected.
2. Description of the Related Art
Recently some computers (information processing devices) have mounted a plurality of physically separated units. For the units, a system board (SB) mounting a CPU and memory and an IO unit mounting a hard disk device, an IO device, a PC slot or the like are usually prepared. This is because a CPU resource and a memory resource can be flexibly assigned according to the situation. In other words, such resources can be efficiently used thus. A computer with such a configuration mounts one or more system boards and IO units. A crossbar is used to connect them each other.
FIG. 1 explains the computer configuration in which a plurality of units is connected by a crossbar. As shown in FIG. 1, one or more system boards 10 and IO units 20 are connected to each of two global address crossbars 30 (hereinafter called “address crossbar”) and each of four global data crossbar 40 (hereinafter called “data crossbar”). A managing board (MB) 50 is an exclusive managing unit and is connected to each of the units 10-40 by an SM bus.
The two address crossbar 30 performs the same request control at the same time. Thereby, the address crossbar 30 is made double in hardware. Four data crossbar 40 is prepared because a lot of data is transmitted usually at once.
“#0” and “#1” are assigned to each of the two address crossbar 30. Thus, when one of the two address crossbar is specified, “#0” or “#1” is attached to the symbol. This also applies to the data crossbars 40.
FIG. 2 explains the configuration example of the system board 10 and the IO unit 20.
The system board 10 comprises four CPUs 101, two FWHs (firmware hub) 102, a north bridge 103, four memory switches (described as “mem. switch” in FIG. 2) 104 and a plurality of pieces of memory 105 connected to each memory switch 104. The IO unit 20 comprises a south bridge 201, two SERs 202 connected to the bridge 201, two ICH6s 203 connected to each SER 202 and six controllers 211-216 connected to each ICH6. As controllers, an FWH 211, an SIO (super IO) controller 212, a BMC (baseboard management controller) 213, a VGA (video graphics array) controller, two LAN adapters 215 and 216 are connected to the ICH6 203. The BMC 213 is used to communicate with the MB 50. The ICH6 203 is an I/O controller hub. The controllers 211-216 shown in FIG. 2 is one example, and its type and quantity can be arbitrarily modified. The controllers 211-216 can also be determined for each IO unit 20.
The south bridge 201 of the IO unit 20 is connected to each of the two address crossbars 30 and four data crossbars 40. The bridge 201 controls each of the controllers 211-216 via the SER 202 and the ICH6 203. When one of the controllers 211-216 transfers obtained data, it issues such a request (address request) and outputs the request to the address crossbar 30. When it receives data to be transferred from the system board 10 via the data crossbar 40, it transmits the data to a controller to which the data should be transmitted via the SER 202 and ICH6 203, and enables the controller to store, output or transmit the data.
Each of the four CPUs 101 on the system board 10 issues a read/write command to the memory 105, another system board 10 or the IO unit 20 and outputs the command to the north bridge 103. The north bridge 103 temporarily stores the commands inputted from each CPU 101, selects one of the commands according to priority, issues the command as a request (address request) and outputs the request to each address crossbar 30 and each of the four memory switches 104.
The data transferred via the data crossbar 40 is received by the memory switch 104, is outputted to the north bridge 103 and is transferred to the CPU 101 which needs the data by the bridge 103. Data to be transferred to another system board 10 or the IO unit 20 is transmitted and transferred to the data crossbar 40 by the memory switch 104. Hereinafter requests issued and outputted from the system board 10 and the IO unit 20 to the address crossbar are called “CPU request” and “IO request”, respectively, for convenience' sake.
Each of the system boards 10 and IO units 20 outputs a request to the address crossbar as requested. Thus, the requests are collected to the address crossbar 30 and there easily remains the same number of un-processed requests as a plurality of units. Therefore, the address crossbar 30 is mounted with an arbiter for selecting one of a plurality of requests issued by different units. FIG. 3 explains the configuration of the conventional arbiter.
Requests issued and outputted by the system board 10 and the IO unit 20 are temporarily stored in a module for system board (hereinafter called “SM module”) 310 and a module for IO board (hereinafter called “IO module”) 320, respectively. The module 310 comprises a plurality of queue buffer units 311 for storing requests for each unit. Each queue buffer unit 311 comprises a queue control unit (described “queue control” in FIG. 3) 312 for controlling the queue buffer units 311 and a request storing buffer 313. The buffer 313 can store a plurality of requests, and “queue 1”-“queue 5” described in FIG. 3 indicate requests stored in the buffer 313. The smaller is the value of a numeral “1”-“5”, the queue is stored earlier. For example, “queue 1” is the request that is stored earliest. The queue buffer unit 311 is also prepared in the IO module 320, which is not shown in FIG. 3. Thus, the same symbols as those of the SM module 310 are also attached to the queue buffer units prepared in the IO module 320.
The conventional arbiter 330 comprises a priority logic (described as “priority” in FIG. 3) 331 and a selector 332. Requests are outputted from the SM module 310 and the IO module 320 to the selector 332 for each queue buffer unit 311. A request outputted by each queue buffer unit 311 is stored earliest.
The queue control unit 312 of each queue buffer unit 311 outputs a queue exist signal indicating whether a request is stored in the buffer unit 313 to the priority logic 331. The logic 331 specifies a unit with an unprocessed request by the signal and selects a unit from which a request should be selected from the units according to a regulated rule (priority rule). The logic 331 outputs a selection signal to the selector 332 according to the selection result to enable the selector 332 to select and output a request from the selected unit. The request is transmitted to the unit to which the request should be transmitted or is broadcast. When it is broadcast, the request is transmitted to the other all units.
The priority logic 331 notifies the queue control unit 312 of a queue buffer unit 311 corresponding to the unit from which a request is selected of the selection of the request. By the notification, the queue control unit 312 erases the selected request. When there remains a request, a request which is stored earliest of the requests is outputted to the selector 332. Thus, only un-processed requests are left in the buffer unit 313. When a newly issued request is received, a free area is sought on the buffer unit 313 and the request is stored in the area.
FIG. 4 explains priority determined by a rule adopted by the conventional arbiter. In FIG. 4, each of “request 1”-“request 8” is issued by different units. Initial priority indicates priority initially determined among the issuing units. For example, the unit that issues “request 1” has top priority and one that issues “request 8” has the lowest priority. A selected request corresponds to one selected and outputted by the selector 332.
Priority among the issuing units is dynamically modified by an actually selected request. When “request 2” is selected, the lowest priority is given to the issuing unit of “request 2” and top priority is given to the issuing unit of “request 3”. Similarly, when “request 5” is selected, the lowest priority is given to the issuing unit of “request 5” and top priority is given to the issuing unit of “request 6”. When “request 8” is selected, the lowest priority is given to the issuing unit of “request 8” and top priority is given to the issuing unit of “request 1”. In other words, priority is retuned to the initial one. Thus, by changing priority every time a request is selected, a request can be uniformly selected from the issuing units.
When selecting a request according to the above-described rule, the actually selected order of requests is as follows according to the situation. The order is described in detail with reference to FIGS. 5A-6B.
FIGS. 5A and 5B show the order of requests selected by the conventional arbiter where five units of the system board 10 and five units of the IO unit 20 are mounted. FIG. 5A shows a unit that issues a request to be selected by the arbiter 330. FIG. 5B shows the actually selected order of requests.
In FIG. 5A, each of “CPU#0”-“CPU#4” indicates requests issued from a different system board 10. Similarly, each of “IO#0”-“IO#4” indicates requests issued from a different IO unit 20. It is because “CPU#0”-“CPU#4” are stored in the SM module that “310” is attached to the frame of those requests. It is for the same reason that “320” is attached to the frame of “IO#0”-“IO#4”.
In this case, priority is given in the order of “IO#0”-“IO#4” and “CPU#0”-“CPU#4”. It is assumed that an unprocessed request exists in all the units. In this state, the priority logic 331 selects requests in the order shown in FIG. 5B. Actually, requests are selected in the order of “IO#0”-“IO#4” and “CPU#0”-“CPU#4” as anticipated.
FIGS. 6A and 6B show the order of requests selected by the conventional arbiter where five units of the system boards 10 and one unit of the IO unit 20 are mounted. Like FIGS. 5A and 5B, FIG. 6A shows a unit that issues a request to be selected by the arbiter 330 and FIG. 6B shows the actually selected order of requests.
In this case, priority is given in the order of “CPU#0”, “IO#0”, “CPU#1”-“CPU#4”. It is assumed that an un-processed request exists in all the units and two “IO#” exist. In this state, the priority logic 331 selects requests in the order shown in FIG. 6B. Actually, requests are selected in the order of “CPU#0”, “IO#0”, “CPU#1”-“CPU#4” and after that, requests are selected in the same order of “CPU#0”, “IO#0”, “CPU#1” and “CPU#2”.
As shown in FIG. 4, by changing priority among issuing units, requests from the units can be uniformly selected (processed). However, in such a request state where each unit issues requests at fairly short intervals, the requests issued by each unit must be sequentially processed (FIGS. 5A and 5B). Therefore, a time until each unit selects a subsequent request after selecting one request becomes long. The time becomes long so that the number of units increases. As shown in FIGS. 6A and 6B, if some unit consecutively issues a plurality of requests, in such a request state, the second request and after are selected only after a request issued by another unit later is selected. Therefore, a time interval until a request is actually selected after it is issued greatly depends on the request state. If a plurality of requests are consecutively issued, there is a possibility that a time interval (process time) until a request is actually selected after it is issued may become very long.
In the unit that issues a request with a very long process time, the using efficiency of the resources decreases and as a result, the overall performance of a computer (system) decreases. When the process time becomes equal to or more than a certain time, that is, times out, it is regarded that the process of an issued request fails and the request is re-issued. Such timeout greatly reduces and sometimes also stops the system. Therefore, it is very important to avoid a request issued from one of the units from being kept un-processed for a long time.
As reference literatures, there are Japanese Patent Application Nos. H05-342178, 2000-112876, 2006-65457 and 2004-5727.